今天要接續上篇，把 Application Pool 剩下的 Advance Settings 看完。

Process Model 其實有點像雜項，參雜了各種類型的設定在這裡，安全性、效能、程式狀況、穩定性等等。第一個 Generate Process Model Event Log Entry 只有一個選項，是 Idle Time-out Reached，這個選項，主要是跟下面的 Idle Time-out 相關，在發生 Idle Time-out 的時候允不允許在 System Log 裡寫下對應事件，如同下圖：

Idle Time-out 主要和 OnDemand 的設定相關聯，在 Application Pool 閒置達這裡設定的時間時，就會把 Process 按設定行為處理，避免佔用資源。預設為 20 分鐘，預設行為為砍了 Process，也可以設置為暫時 Suspend。

Identity 的設定項展開會像這樣子，有兩個選項可以選擇，一個是 Built-in account，一個是 Custom account。基本關係到 Application 起 Process，網站嘗試存取資料夾等行為使用的認證身分帳號，Default 為 ApplicationPoolIdentity (IIS 7.5 開始)。

撇除 Custom account，Built-in account 的權限高低依序為 Local System 最高，擁有本地系統全部權限，再來是 Network Service 少了一些高級權限，仍保有網路存取能力，Local Service 則是比 Network Service 再少了網路存取權限，這些帳號都能實際在本地帳號管理中找到。Application Pool Identity 則是比較後來的 IIS 版本發展出來的權限，並非實際存在的帳號，專門用於 IIS 服務，權限等同 Network Service。好處在於以往只有 Network Service 的時候可能會有權限變相等於開給不同 App 間彼此干擾的疑慮，在有了 Application Pool Identity 後，不同的 Application Pool 就能以不同的帳號權限來做相關設置。

上圖就是 Application Pool Identity 運行 Process 的狀況，可以從 user name 一欄識別(也能夠看到上面提到其他的 Built-in account)。

Load User Profile 關係到暫存檔案的創建行為，會歸於系統或於 User Profile 底下，差異大概是像 C:\Users\UsingAccountName\AppData\Local\Temp 和 C:\WINDOWS\Temp 這樣的差別。如果是從 IIS6 搬來的網站可以設為 False 讓行為一致，後面預設沒發生問題，也不會特別對暫存檔案做到操作，那可以不用調整。

Maximum Worker Process 當值設定大於 1，IIS 將會套用 Web Garden 的設置，意即盡可能起到如同設定上限的 Process 數，盡量利用 Multi Processor 的效能。套用要謹慎考慮到的是當你的 Application 會有 Session 儲存認證的部分，不同 Process 的 Session 不會共用，而近來的 Request 並不保證每次都會到同一個 Session，故可能造成認證失敗的結果。套用這個設置要注意先評估過自己的 Application 是否合適使用，或是針對這個情況做一些調整。

Ping 相關指的是對 Process 的 Health Check 是否被 Enabled，如果是 Enabled 就會依 Ping Period 去確認 Process 的健康狀況(是否有在 Ping Maximum Response Time 內回覆)。

Shutdown Time Limit 是指如 Recycle Application Pool 時會讓舊的繼續處理完當前的 Request 再做回收 Process，為避免舊的 Process 存在過久，當遇到這個設定的 Time Limit 仍未處理完的時候，就會強制進行 Shutdown 與回收。Startup Time Limit 則是指 Process 起來程序開始到起來為止，若是超過這個時間可能碰上什麼問題，就會強制停止該次嘗試，避免過久資源占用。

Rapid-Fail Protection 很常造成大家的困惑，但他本意是個善良的功能。Rapid-Fail 的意思就是快速的失敗，那快速的失敗如何被定義？在 Failure Interval (minutes) 中，嘗試確認 Process 狀態時總計累計達 Maximum Failures 次數的 “Service Unavailable” Response Type 類型的錯誤，就會被視作Rapid-Fail 條件達成，把 Application Pool 做 Disabled，停止運行並留下相關的 Event Log。以這邊截圖中的預設數值，它反應的設定就是 Process 5 分鐘內遇到 5 次 Http Level 的錯誤(Crash)，那麼就會停止該 Application Pool 並不再嘗試。停止嘗試的目的是避免當下有問題的 Application 過度消耗系統資源，致使影響同個系統裡的其他服務。

在每次定義的錯誤類型被觸發的當下，System Event Log 會留下 Event Id 5011 的事件，可以查看每次錯誤發生的時間，一般觸發的 Pattern 是 5011 五次，5002 一次，5002 就是真正停止 Application Pool 的事件。關於 Event Viewer 的細節我們後面再補充怎麼去查看。

這邊也留下了機制觸發的 Workaround，可以在 Shutdown Executable 和 Parameters 中寫下當停止時要運行什麼樣的命令，如 Load Balance Health Check 檔案的狀態改寫、節點轉導之類的。

Recycling 這塊就是和 Recycle Application Pool 相關的設定，包含 Recycle 的行為、Recycle 的觸發和相關 Log 的撰寫。

Recycle 的行為包含的是 Disable Overlapped Recycle 和 Disable Recycling for Configuration Changes。前者處理的行為是 Recycle 時會不會在舊的 Process 還沒停止前就起新的，讓他們同時存在，而預設是會。設定為 True 來關掉這個功能的情況通常是 Application 不允許同時有多個 Instance 存在，會造成一些錯誤的情景。後者是關於 Application Pool 相關的設定改動的時候，Application Pool 本身是否會立刻重啟套用，預設是會重啟套用，這個就看操作的習慣跟意識設定。

Generate Recycle Event Log Entry，這邊是可以針對各個原因造成的 Application Pool Recycle 是否要寫下 System Event Log 來做設定，預設是全開，基本上也是維持全開就好。畢竟當問題發生的時候，大家都想有多一點線索能夠調查，是吧？

剩下的其他項目是關於條件到達的 Application Pool Recycle，Memory 到達的回收可以分別設置 Virtual Memory 或 Private Memory，或是限制總處理的 Request 量，而 IIS 的預設是時間定時回收。在沒有改任何設定的時候，這邊的定期回收時間是 1740 分鐘，等同 29 小時，是 24 之後的最小質數，意即夠久的話它會在每個不同的時間點都做過回收。如果不想要這種不定時的回收，也可以設做 0 來不進行回收，但通常建議可以的話盡量在非尖峰時段能做一下回收，畢竟重啟能解決很多問題(如異常資源占用，但重啟對非 stateless 的 Application 同時也可能會造成很多問題就是了)。透過設定下面 Specific Time 的部分可以設定回收的小時，設定的時候要注意的就是時區吧，遠端架設的機器可能跟你自己所在時區不同，務必確認該台電腦的時區，避免在尷尬的時間做了回收。

這樣就講完了全部的 Application Pool 的 Advance Setting，老實說要看一遍就記住也完全搞懂是不太可能的。通常是看過有印象，知道就好，要用的時候再細查即可。對於新接手管理的 Application 或新架設的 Web Server 最好也巡一下設定，確保設定如預期，避免藏著一些驚喜在裡頭。